A business may use a software application, such as a web service, to automate business processes and to interact with other entities in a distributed environment, such as the Internet or World Wide Web. To ensure that such interactions are accomplished successfully, one or more protocols should be in place for carrying messages to and from participants, and specific business applications should also be in place at each participant's end. Such interactions are message-driven. For example, a buyer sends a purchase order to a seller. The seller then checks its inventory to determine if it can provide the ordered items. If so, the seller sends an acknowledgement back to the buyer with a price. Finally, the buyer accepts or rejects the seller's offer (and/or possibly places another order). As evident in this example, each participant's business application reacts to the receipt of messages.
Such message-based transactions may not be completed for a relatively long period of time (e.g., if the seller takes several days to check its inventory before responding to the purchase order). As a result, information regarding the state of the application must be stored, or “persisted,” so as to complete the transaction successfully when, for example, a response is finally received. Persisting the state of the application also makes the application less prone to errors. For example, if the application is shut down due to a power failure the stored state information allows the application to resume in the same state when the application is restarted as when the failure occurred.
Accordingly, a distributed transactional application is a software application that runs in a distributed environment and persists the state of the application data in a server in a transactional manner. An example of such a distributed transactional application is business process orchestration software, which enables the automated management of multiple instances of a business process. In such software, the code that implements a particular business process is referred to as an “orchestration service,” and one or more orchestration services may run concurrently on a single “host service.” Business process orchestrations may be implemented using a business process software language such as, for example, XLANG/s. Business process software languages such as XLANG/s are said to handle messages in an “asynchronous” manner, because, as noted above, a message may not immediately generate a response or status indicator.
When messages are sent by software, an “ACK/NACK” message is typically sent by the receiving party to either confirm the receipt of the message or to notify the sender of an error. Thus, a developer who is creating software to handle traditional synchronous messaging needs only to include a “try-catch” code block to process the ACK/NACK message and handle any errors. A try-catch code block defines a block of statements that is capable of handling exceptions that occur during the execution of those statements. The use of try-catch blocks for handling program exceptions when processing synchronous messages is familiar to developers and easy to implement.
While asynchronous message handling is essential for effectively automating business processes, such message handling causes programming complications as compared to its synchronous counterpart. For example, business process software that handles asynchronous messaging typically does so by way of compensation handlers that operate outside the context of the main program. Such placement of the compensation handler is necessary because the main program cannot wait for the acknowledgement or error notification that, as noted above, may not arrive for a long period of time. As a result, XLANG/s permits the business process to continue and uses compensation handlers to, as the name implies, compensate for any message failures. Using the buyer/seller example discussed above, a compensation handler may recognize that a particular business transaction did not complete properly, and that the buyer's account should be credited with the purchase price. Thus, the compensation handler may send another message to credit the buyer's account.
Because it is handled outside of the context of the main program, a compensation handler adds complexity to the automation of the business process. For example, the developer must keep track of what the main program is doing and what processes have been completed so as to create a compensation handler that will take appropriate actions to rectify errors. Otherwise, the compensation handler may not properly compensate for the message error, or may even create new errors.
Accordingly, and in light of the above shortcomings, what is needed is a method for handling asynchronous message errors in a manner that enables error handling within the main program. More particularly, what is needed is a method for handling asynchronous message errors with a synchronous-type try-catch code block. Even more particularly, what is needed is a method of pausing the main program until an ACK/NACK message is received, and then resuming the program so as to enable handling of the ACK/NACK message using a try-catch block.